* build: use transition to build wasm binary

Signed-off-by: Lizan Zhou <lizan@tetrate.io>

…r.rst (envoyproxy#498)

Description: create a class to manage Envoy lifecycle and allow for graceful teardown. Teardown is now graceful for both iOS and Android. Envoy's codebase expects to have shutdown happen from the main thread. However, in mobile the thread the engine runs in is not the main thread of the process, and thus shutdown/destructors were not getting run from the thread the engine was started on. This PR makes sure that the engine is destructed/shutdown from the thread that it ran in.
Risk Level: high. This PR changes state management for the engine, and initializes it on a std::thread instead of a platform thread. iOS thread management is afaict handled gracefully. On Android the native thread has to be attached and detached from the JVM. This PR attaches the native thread, but the work to detach is a bit involved so will come in a subsequent PR.
Testing: local device testing.

Fixes #492

Co-authored-by: Jose Nino <jnino@lyft.com>
Signed-off-by: Mike Schore <mike.schore@gmail.com>
Signed-off-by: JP Simard <jp@jpsim.com>

Description: this is a follow up to #498. This PR introduces `envoy_engine_callbacks`. They are similar in nature to envoy_http_callbacks. The difference being that they are not exposed all the way to consumer level in the library as it is not needed right now. However, one can see how by adding a type erased context pointer, and following the platform patterns for http callbacks we could thread this all the way up if need be. The immediate need for these callbacks is to detach the engine's native thread from the JVM on Android.
Risk Level: med -- adds complexity to engine management.
Testing: local testing on devices (Lyft and example app on iOS and Android).

In conjunction with #498 this PR Fixes #492 #445

Signed-off-by: Jose Nino <jnino@lyft.com>
Signed-off-by: JP Simard <jp@jpsim.com>

Description: #498 did not fully solve #492. The reset cleanly destructed all objects. However, because destruction was posted in to the event dispatcher, the event dispatcher was left with bad accesses.

This PR fixes the issue by issuing shutdown on the dispatcher, and only destructing once the event loop has exited and control has returned to the Engine's run function.

Risk Level: med - fixing crash on shutdown
Testing: local

Fixes #492

Signed-off-by: Jose Nino <jnino@lyft.com>
Signed-off-by: JP Simard <jp@jpsim.com>

Description: "Recent changes (namely #498) made it unnecessary for the platform-level clients to start Envoy on newly spawned threads. In fact, these changes actually introduced potential races where consumers of the platform clients could end up calling send on engines that hadn't finished starting on these threads."

This PR removes the custom threading logic in Kotlin in favor of simply using the new threading being done within the core. Parallel to #530.
Risk Level: med - reduce threading complexity
Testing: local app.

Signed-off-by: Jose Nino <jnino@lyft.com>
Signed-off-by: JP Simard <jp@jpsim.com>

Description: create a class to manage Envoy lifecycle and allow for graceful teardown. Teardown is now graceful for both iOS and Android. Envoy's codebase expects to have shutdown happen from the main thread. However, in mobile the thread the engine runs in is not the main thread of the process, and thus shutdown/destructors were not getting run from the thread the engine was started on. This PR makes sure that the engine is destructed/shutdown from the thread that it ran in.
Risk Level: high. This PR changes state management for the engine, and initializes it on a std::thread instead of a platform thread. iOS thread management is afaict handled gracefully. On Android the native thread has to be attached and detached from the JVM. This PR attaches the native thread, but the work to detach is a bit involved so will come in a subsequent PR.
Testing: local device testing.

Fixes #492

Co-authored-by: Jose Nino <jnino@lyft.com>
Signed-off-by: Mike Schore <mike.schore@gmail.com>
Signed-off-by: JP Simard <jp@jpsim.com>

Description: this is a follow up to #498. This PR introduces `envoy_engine_callbacks`. They are similar in nature to envoy_http_callbacks. The difference being that they are not exposed all the way to consumer level in the library as it is not needed right now. However, one can see how by adding a type erased context pointer, and following the platform patterns for http callbacks we could thread this all the way up if need be. The immediate need for these callbacks is to detach the engine's native thread from the JVM on Android.
Risk Level: med -- adds complexity to engine management.
Testing: local testing on devices (Lyft and example app on iOS and Android).

In conjunction with #498 this PR Fixes #492 #445

Signed-off-by: Jose Nino <jnino@lyft.com>
Signed-off-by: JP Simard <jp@jpsim.com>

Description: #498 did not fully solve #492. The reset cleanly destructed all objects. However, because destruction was posted in to the event dispatcher, the event dispatcher was left with bad accesses.

This PR fixes the issue by issuing shutdown on the dispatcher, and only destructing once the event loop has exited and control has returned to the Engine's run function.

Risk Level: med - fixing crash on shutdown
Testing: local

Fixes #492

Signed-off-by: Jose Nino <jnino@lyft.com>
Signed-off-by: JP Simard <jp@jpsim.com>

Description: "Recent changes (namely #498) made it unnecessary for the platform-level clients to start Envoy on newly spawned threads. In fact, these changes actually introduced potential races where consumers of the platform clients could end up calling send on engines that hadn't finished starting on these threads."

This PR removes the custom threading logic in Kotlin in favor of simply using the new threading being done within the core. Parallel to #530.
Risk Level: med - reduce threading complexity
Testing: local app.

Signed-off-by: Jose Nino <jnino@lyft.com>
Signed-off-by: JP Simard <jp@jpsim.com>

**Commit Message**

This scaffolds `aigw run [path]` command that allows users to run AI
Gateway natively without k8s/docker.

**Related Issues/PRs (if applicable)**

Extracted from #458
Contributes to #412

---------

Signed-off-by: Takeshi Yoneda <t.y.mathetake@gmail.com>

**Commit Message**

This implements the `aigw run` command that runs the AI Gateway locally.
This utilizes the Envoy Gateway's standalone mode [1]. With this
command, users are now able to use the AI Gateway, without Docker or
Kubernetes. The follow up PRs to further modify the default
configuration to add more de-facto services such as ollama, and will add
the command to show the default configuration.

1:
https://gateway.envoyproxy.io/docs/tasks/operations/standalone-deployment-mode/

**Related Issues/PRs (if applicable)**

Contributes to #412 
Follow up on #498

---------

Signed-off-by: Takeshi Yoneda <t.y.mathetake@gmail.com>